Hopefully, all your PHP has ben updated against PHP2shell
From: Mike Harrison Via chugalug ------------------------------------------------------ From: Mike (meuon) Harrison mike geeklabs.com: - - - - - - - - - - - - - - - - - - - - - - - - - - - - ' Double checking my public facing stuff with PHP this morning after updates/upgrades and reboots last night. I knew there was a reason to try to keep key systems on reasonably current versions of well supported Linux. Thanks Debian. :) Hope ya'll are doing well. -- Mike Harrison mike@geeklabs.com mobile: 423 605-6943=============================================================== From: Dan Lyke Via chugalug ------------------------------------------------------ From: Dan Lyke danlyke flutterby.com: - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dumb q: I've got a bunch of little PHP scripts that don't read anything, they just send some headers and a gzip bomb (paths derived from going through my error log looking for 404s that end in .php). I've upgraded, but was there likely any issue in those? I don't know enough about how PHP handles requests, and what this error was, to know. On Thu, Oct 22, 2026 at 3:45=E2=80=AFAM Mike Harrison Via chugalug wrote:
=============================================================== From: Tyler Holcomb Via chugalug ------------------------------------------------------ From: Tyler Holcomb tyler tholcomb.com: - - - - - - - - - - - - - - - - - - - - - - - - - - - - Any PHP serving web requests was vulnerable. Apache/mod_php being exploitab= le prior to any application code running. https://www.php.net/archive/2026.php#2026-10-21-5 - Tyler
=============================================================== From: Dan Lyke Via chugalug ------------------------------------------------------ From: Dan Lyke danlyke flutterby.com: - - - - - - - - - - - - - - - - - - - - - - - - - - - - My server is patched, but I'm trying to figure out how much time to spend looking for intrusions (or migrating to a new clean server). https://eliastaylor.com/noexploit/ claims there's no PoC exploit that doesn't also take advantage of an additional vulnerability in a script. So I'm taking a little bit of a breath for the moment... Some days I consider just rewriting it all in C... On Thu, Oct 22, 2026 at 7:40=E2=80=AFAM Tyler Holcomb Via chugalug wrote: ab=3D hugalug
=============================================================== From: Sumit Khanna Via chugalug ------------------------------------------------------ From: Sumit Khanna sumit penguindreams.org: - - - - - - - - - - - - - - - - - - - - - - - - - - - - From the early reports I thought it depended on abusing file upload progress, but the demo videos show payloads being injected on a 404 URL and then getting a page, which seems to match the attack vector in that link that was posted. I'm not sure how you'd go around checking if you've been pwned. I only have a few PHP things I self-host and I stopped them all the night prior to the release. They're in containers, so I just deleted/rebuild them afterwards.
=============================================================== From: Mike Harrison Via chugalug ------------------------------------------------------ From: Mike (meuon) Harrison mike geeklabs.com: - - - - - - - - - - - - - - - - - - - - - - - - - - - - I've been involved with a lot of server compromises, only a few over recent years. Biggest simple tells: Shell in and things seem weird. Slow, sticky, not right. hard to define. ps -axf - Might show it. Might not. Often process lists functions get changed and they don't show the issue. I've replaced ps and found new processes that did not show on the old one. Modern exploits may not do this any more because it's so rare users login as root and check for such things in the modern removed from being a "old skool sysadmin". Same for logging. Drive usage. - Missing a munch of space? cpu usage? - whats doing all that work? /var/log/* - new stuff in /var/log/... entries that look weird. iptraf / iptraf-ng - Hmmm.. those are interesting ports and traffic patterns I have not seen before. But the great tells are usually in the hosting company dashboard: Bandwidth usage / cpu usage changes. The hard part is when a machine has been compromised, but not exploited yet. -- Mike Harrison mike@geeklabs.com mobile: 423 605-6943 ===== | chugalug COULD NOT VERIFY mike@geeklabs.com as the sender nor content validity =====
=============================================================== From: Sudo Bash Via chugalug ------------------------------------------------------ If it wasn't public facing, you're highly likely fine. By the way, those are all old methods of checking for compromise. Nowadays, they're hiding activity in eBPF / bpfprogs and even EFI / hardware based bluepill rootkits that are hard to detect and remove.
=============================================================== From: Mike Harrison Via chugalug ------------------------------------------------------ From: Mike (meuon) Harrison mike geeklabs.com: - - - - - - - - - - - - - - - - - - - - - - - - - - - - True. But Old school still valid, In shared hosted systems, Digital Ocean, Linode, Etc.. detecting such and mitigating the more exotic means are much harder and often beyond the end user/sysadmin's control.